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METHOD AND APPARATUS FOR DISTRffiUTING AND UPDATING 
PRIVATE KEYS OF MULTICAST GROUP MANAGERS USING DIRECTORY 

REPLICATION 



5 FIELD OF THE INVENTION 

The invention generally relates to secure network communication systems. 
The invention relates more specifically to a method and apparatus for distributing and 
updating private keys that are used by group managers of broadcast or multicast 
groups based on directory replication, 

10 BACKGROUND OF THE INVENTION 

The proliferation of network computing has shaped how society conducts 
Q business and personal communication. As reliance on computer networks grows, the 

Iz flow of information between computers continues to increase in dramatic fashion. 



Q Accompanying this increased flow of information is a proportionate concem for 

B 

ijl 15 network security. Commercial users, who regularly conduct business involving the 

^' exchange of confidential or company proprietary information over their computer 

p.. networks, demand that such information is secure against interception by an 

2t unauthorized party or to intentional corruption. In addition, with the acceptance of 
electronic commerce over the global Intemet, all users recognize the critical role 



20 cryptographic systems play in maintaining the integrity of network communication. 

Cryptography is the art and science of keeping messages secure. A message is 
information or data that is arranged or formatted in a particular way. In general, a 
message, sometimes referred to as "plaintext" or "cleartext," is encrypted or 
transformed using a cipher to create "ciphertext," which disguises the message in 

25 such a way as to hide its substance. In the context of cryptography, a cipher is a 
mathematical function that can be computed by a data processor. Once received by 
the intended recipient, the ciphertext is decrypted to convert the ciphertext back into 
plaintext. Ideally, ciphertext sufficiently disguises a message in such a way that even 
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if the ciphertext is obtained by an unintended recipient, the substance of the message 
cannot be discerned from the ciphertext. 

Many different encryption/decryption approaches for protecting information 
exist. In general, the selection of an encryption/decryption scheme depends upon the 
considerations such as the types of communications to be made more secure, the 
particular parameters of the network environment in which the security is to be 
implemented, and desired level of security. An important consideration is the 
particular system on which a security scheme is to be implemented since the level of 
security often has a direct effect on system resources. 

For example, for small appHcations that require a relatively low level of 
security, a traditional restricted algorithm approach may be appropriate. With a 
restricted algorithm approach, a group of participants agree to use a specific, 
predetermined algorithm to encrypt and decrypt messages exchanged among the 
participants. Because the algorithm is maintained in secret, a relatively simple 
algorithm may be used. However, in the event that the secrecy of the algorithm is 
compromised, the algorithm must be changed to preserve secure commxmication 
among the participants. Scalability, under this approach, is an issue. As the number 
of participants increases, keeping the algorithm secret and updating it when 
compromises occur place an undue strain on network resources. In addition, standard 
algorithms cannot be used since each group of participants must have a unique 
algorithm. 

To address the shortcomings of traditional restricted algorithm approaches, 
many contemporary cryptography approaches use a key-based algorithm. Generally 
two types of key-based algorithms exist: (1) synunetric algorithms and (2) 
asymmetric algorithms, of which one example is a public key algorithm. As a 
practical matter, a key forms one of the inputs to a mathematical function that is used 
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by a processor or computer to generate a ciphertext. 

Public key algorithms are designed so that the key used for encryption is 
different than the key used for decryption. These algorithms are premised on the fact 
that the decryption key cannot be determined from the encryption key, at least not in 
any reasonable amoimt of time with practical computing resources. Typically, the 
encryption key (pubUc key) is made public so that anyone, including an eavesdropper, 
can use the public key to encrypt a message. However, only a specific participant in 
possession of the decryption key (private key) can decrypt the message. 

PubHc key algorithms, however, often are not employed as a mechanism to 
encrypt messages, largely because such algorithms consume an inordinate amount of 
system resources and time to encrypt entire messages. Further, pubUc key encryption 
systems are vuhierable to chosen-plaintext attacks, particularly when there are 
relatively few possible encrypted messages. 

As a result, a public key cryptosystem generally is utilized to establish a 
secure data communication channel through key exchanges among the participants. 
Two or more parties, who wish to communicate over a secure channel, exchange or 
make available to each other public (or non-secure) key values. Each party uses the 
other party's public key value to privately and securely compute a private key, using 
an agreed-upon algorithm. The parties then use their derived private keys in a 
separate encryption algorithm to encrypt messages passed over the data 
communication channel. Conventionally, these private keys are valid only on a per 
communication session basis, and thus, are referred to as session keys. These session 
keys can be used to encrypt/decrypt a specified number of messages or for a specified 
period of time. 

A typical scenario involves participants A and B, in which user A is 
considered a publisher of a message to a subscriber, user B. The public key algorithm 
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used to establish a secure channel between publisher, A, and subscriber, B, is as 
follows: 

1 . B provides a public key, B, to A. 

2. A generates a random session key SK, encrypts it using public key B 
and sends it to B. 

3. B decrypts the message using private key, b ( to recover the session 
key SK). 

4. Both A and B use the session key SK to encrypt their communications 
with each other; after the conmiunication session, A and B discard SK. 

The above approach provides the added security of destroying the session key at the 
end of a session, thereby, providing greater protection against eavesdroppers. 

Once a multicast group is established, management of the sessions keys due to 
membership changes poses a number of problems. Forward secrecy, which arises 
when a member node leaves the multicast group and may still possess the capabiUty 
to decipher future messages exchanged among the group, becomes a concem. In 
addition, in the case where a new member node enters the multicast group, the new 
member should not be permitted to decrypt the past messages of the multicast group. 
Another consideration involves making session key updates when a "join" or "leave" 
occurs; updates must be rapid to prevent undue system delay. This issue relates to 
how well the network scales to acconmiodate additional users. 

Another conventional technique used to establish secure communication 
employs a trusted third party authentication mechanism, such as a certificate authority 
("CA") or key distribution center ("KDC") to regulate the exchange of keys. FIG. 9 
is a block diagram of a system that uses a single central group controller (GC) 901 
that has responsibility for distributing, creating, and updating session keys to 
members of the multicast group (users A-H). The eight users, A-H, communicate 
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with group controller 901 via separate point-to-point connections 903 to obtain a 
dynamic group session key. The channels 903 can be made secure by using a standard 
Diffie-Helhnan key exchange protocol. 

The group controller preferably comes to a shared Group Session key using a 
binary tree approach. The KDC or CA carries out a third party authentication. The 
keys can be sent in a multicast or broadcast messages or overlapping broadcast or 
multicast messages or many point to point messages. Diffie-Hellman is not required 
to secure communications with the group controller; the binary tree approach 
provides it. Ideally, only one message from the group controller is needed. 

Alternatively, Diffie-Hellman is used to do a point to point communication 
with the CA or KDC, and the CA or KDC can give out a group session key without 
using the binary tree approach. All nodes get the same session key using N-1 point to 
point messages. These two approaches are orthogonal and can be combined for 
optimization. 

To set up the secured channel among the nodes, N - 1 messages are 
exchanged, wherein N is the number of nodes. Although this is relatively low 
overhead in terms of messages exchanged, a major drawback is that the centrahzed 
group controller 901 represents a single point of failure, and therefore the system 
lacks fault tolerance. If the group controller 901 is down, no secure communication 
can exist among the multicast group of users A-H. Such a prospect is unacceptable, 
especially in mission critical systems. 

Another drawback is that the group controller 901 is a potential bottleneck in 
the network when a binary tree algorithm is used, and the KDC or C A are potential 
bottlenecks when other mechanisms are used. For instance, if multiple nodes request 
to join the multicast group, the controller 901 may not be able to process all such 
requests in a timely manner. This problem may be acute if the multicast group is over 
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a wide area network (WAN). Further, a system dependent upon a group controller 
901 is not easily enlarged or scaled, due, in part, to physical hardware constraints. 

A binary tree approach is disclosed in co-pending application Ser. No. 
09/407,785, entitled "METHOD AND APPARATUS FOR CREATING A Secxjre 
Communication Channel Among Multiple Proxy Multicast Service 
Nodes," filed September 29, 1999, and naming as inventors Sunil K. Srivastava, 
Jonathan Trostle, Raymond Bell, and Ramprasad GoUa, the entire disclosure of which 
is hereby incorporated by reference as if fully set forth herein. The binary tree 
approach described therein makes it possible to scale a secure communication system 
to large multicast groups, with less overhead involved in transmission of new group 
session keys when members join in a multicast group. Advantageously, each affected 
member does only logjN decryption operations; further, when a member joins or 
leaves, the central group controller, which acts as a group membership coordinator, 
sends only a subset of keys to existing group members on an affected tree branch. All 
keys that are affected can be sent, ideally, in one multicast or broadcast message, and 
only keys that correspond to a particular node will be decrypted by that node. 

One issue with this approach, however, is that the central group controller 
presents a single point of failure. The KDC and C A also present a single point of 
failure in approaches that do not use a binary tree mechanism.Still another drawback 
is that key distribution requires complicated synchronization procedures and 
specialized sending and listening mechanisms. 

Based upon the foregoing, there is a clear need for improved approaches to 
key exchange that eliminate a single point of failure, especially among broadcast or 
multicast group members. 

There is also a need for an approach for providing a secure communication 
channel among a group controller, KDC, or CA so that the group controller, KDC or 
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CA may be distributed. Since the group controller, KDC, and CA normally are 
essential for establishing any secure channel, this need presents a circular or "chicken 
and egg" type of paradox. 

In particular, there is an acute need for an improved approach todistribution 
that enhance scalability and fault tolerance, particularly over a WAN. 

There is also a need for improved approaches for key updating. 

There is a specific need for improved approaches for key distribution and 
updating that can take advantage of computing infi*astructure that is used for other 
purposes in the secure communications system without requiring a special mechanism 
for the purpose of key distribution and updating. 
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SUMMARY OF THE INVENTION 

The foregoing needs and objects, and other needs and objects that will become 
apparent from the following description, are fulfilled by the present invention, which 
comprises, in one aspect, an approach for establishing secure multicast 
communication among Muhiple Multicast Key Distribution Services, or Multicast 
Group Controllers that also can act like a proxy to Multicast Service nodes (called 
"multicast proxy service nodes" herein) is disclosed. The multicast proxy service 
nodes, which can be distributed throughout an enterprise domain, are organized in a 
logical tree that mimics the logical tree arrangement of domains in a directory server 
system. The attributes of the event service nodes include the group session key and 
the private keys of the event service nodes that are members of the multicast or 
broadcast groups. The private keys provide unique identification values for the event 
service nodes, thereby facilitating distribution of such keys. Because keys as well as 
key version information are housed in the directory, muUicast security can be 
achieved over any nxmiber of network domains across the entire enterprise. Key 
information is stored in, and the logical tree is supported by, a directory service. 
Replication of the directory accomphshes distribution of keys. Event service nodes 
may obtain current key information from a local copy of the rephcated directory. 

When the information is replicated across the network or enterprise, local 
copies of the directory can be used to obtain a common group session key. It cannot 
support dynamic groups, however, the MKDCs are trusted nodes that do not often fail 
and restart; accordingly, the DSA can be used to send a group session key. To ensxure 
continued secured communication, changing the group session keys periodically 
among the MKDCs is desirable. An MSA that is specific to a pubUsher generates a 
number of keys sufficient to enable it to cycle through numerous group session keys 
to prevent an unauthorized user from intercepting and using these keys. Such keys 
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may be selected among MKDCs based on providing their date and timestamp to 
algorithm that generates a key version value. 
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BRIEF DESCRIPTION OF THE DRAWINGS 

Embodiments are illustrated by way of example, and not by way of limitation, 
in the figures of the accompanying drawings in which like reference numerals refer to 
similar elements and in which: 

FIG. 1 is a block diagram of a secure communication system employing a 
central authority such as a key distribution center (KDC). 

FIG. 2A, FIG. 2B, and FIG, 2C are block diagrams of a secure network 
utilizing a group controller (GC). 

FIG. 3 is a block diagram illustrating the security mechanisms for providing 
secure conraiunication between two participants in the system of FIG. 1. 

FIG. 4A, FIG. 4B, FIG. 4C, and FIG. 4D are diagrams illustrating methods for 
key exchange. 

FIG. 5 is a diagram of a binary tree approach to key management used in the 
systems of FIG. 2A, FIG. 2B, and FIG. 2C. 

FIG. 6A and FIG. 6B are a flow chart and a diagram, respectively, ofan 
exemplary embodiment of the operation of the group controller of FIG. 2A, FIG. 2B, 
FIG. 2C related to joining of the multicast group. 

FIG. 7A andFIG. 7B are a flow chart and a diagram, respectively, ofan 
exemplary embodiment of the operation of a group controller of FIG. 2 A, FIG. 2B, 
FIG. 2C related to leaving the multicast group, 

FIG. 8 is a block diagram of a computer system on which embodiments of the 
group controller of FIG. 2 A, FIG. 2B, FIG. 2C may be implemented. 

FIG. 9 is a diagram of a conventional secure communication system using a 
single centralized group controller. 
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DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT 

In the following description, for the purposes of explanation, specific details 
are set forth in order to provide a thorough understanding of the invention. However, 
it will be apparent that the invention may be practiced without these specific details. 
In some instances, well-known structures and devices are depicted in block diagram 
form in order to avoid unnecessarily obscuring the invention. 

An approach for creating a secured multicast or broadcast group in a 
communications network uses a distributed system to disseminate and update group 
session keys. To establish a secured channel among the participating muhicast group 
members, a group controller approach is used. However, functionality of the group 
controller is distributed across muhiple entities, which themselves commxmicate over 
a secure channel. The entities, which make up the group controller, use various key 
exchange algorithms to securely communicate. The key exchange protocols generate 
session keys based on a public key scheme, without needing to rely on a group 
controller approach. Further, the approach exploits the commonality between the 
physical topology of directory based domains (as well as multicast routing trees) and 
the structure of a binary tree to generate a network of group controllers that efficiently 
manages membership within a secure multicast or broadcast group. 

In a basic public key encryption approach, a group of participants publish their 
pubUc keys, for example, in a database, and maintain their own private keys. These 
participants can access the database to retrieve the public key of the participant to 
whom they want to send a message and use it to encrypt a message destined for that 
participant. Unfortunately, the database, even if secure, is vuhierable to key 
substitution during transmission of the keys. 

This problem is alleviated by using a trusted intermediary, called a Central 
Authority (CA), Key Distribution Center (KDC) or Group Controller (GC), which has 
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the responsibility of distributing the stored public keys to the multicast or broadcast 
group members. The KDC accomplishes this task by encrypting the public keys with 
its private key, which is shared with each of the group members. The group members 
then decipher the encrypted message to determine each others' public keys. In 
addition to pubUshing public keys by which session keys may be derived by the group 
members, the KDC may distribute actual session keys. 

FIG. 1 shows an exemplary implementation with four users A, B, C, D 
connected via network 101. The network 101 may be a packet switched network, 
which supports the Intemet Protocol (IP). A Central Authority 111, which is a third 
party trusted authentication authority, is hosted in network 101. In a preferred 
embodiment, Central Authority 1 1 1 is a distributed multicast subnetwork made up of 
multiple KDCs, CAs, or GCs that are interconnected over secured channels in a 
hierarchical relationship. Among other functions, the Central Authority 111 provides 
authentication and validation services when individual nodes join the multicast or 
broadcast group. Although four (4) users A, B, C, D are shown as an example, any 
number of users or nodes can be used. 

Central Authority 1 1 1 may be a KDC subnetwork in an environment that uses 
an exchange of Kerberos credentials for communications security. However, any 
other suitable central authority mechanism may be substituted. For example, a 
certificate authority (CA) may be used as Central Authority 111 when a public key 
infrastructure (PKI) is used for communications security in the network. 

Central Authority 1 1 1 establishes point-to-point conmnmication with the 
workstations 103, 105, 107, 109 to authenticate them. Workstations 103, 105, 107, 
109 obtain dynamic session keys from the Central Authority 1 1 1 for subsequent 
secure communication among themselves. In this case. Central Authority 1 1 1 
generates the session key. Alternatively, one of the nodes 103, 105, 107, 109, which 
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initiates communication with the multicast group, may generate and supply a dynamic 
group key based on a symmetrical cryptographic algorithm to the Central Authority 
111. Thereafter, other nodes seeking to participate in the secure communication may 
do so by requesting this group session key from the Central Authority 111, distributes 
5 it using secured point-to-point communication. 

For purposes of illustration, assxune that user A desires to publish a message 
to the other users B, C, D, As a publisher, user A encrypts the message with the 
dynamic group session key and signs a message digest with its private key. The 
message digest can include a time-stamp and serial numbers for authentication 
10 purposes. If user A is trusted by the other users B, C, D, user A itself can assume the 
42 roleofaKDC. 

If each of the members of the multicast group (e.g.. A, B, C, D) can be either a 
pubUsher or a subscriber, then each individual group member can employ the group 
session key when it publishes a message. Subscribers are required to know the group 
15 session key to decrypt the message. Normally the group session key is not used as a 
signature because it could be used to spoof a publisher and send an unauthorized 



»?• 

a 

?* 
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m 

nJ message. Accordingly, third party authentication is used and message signatures are 

4} constructed from a publisher's private key, message digest and time stamp. 

In an exemplary embodiment, the group members initially authenticate 
20 themselves by using a certificate authority (CA) or a Kerberos KDC, in which case 
the session keys need not serve as authentication signatures or certificates. Kerberos 
is a known key based authentication service. The directory can provide Kerberos 
service on a number of operating systems (e.g,, Windows, UNIX, etc.). A CA may be 
used with SSL, TLS or Kerberos providers may be used with the Generic Security 
25 Service Application Programming Interface (GSS-API). 

Central Authority 1 1 l,like the GC or KDC, in a preferred embodiment, is a 
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distributed Multicast KDC ("MKDC"), whereby a designated or root MKDC tracks 
group membership information and conveys such information to the other MKDCs. 
(In this disclosure, all references to an MKDC also mean, additionally or 
altematively, a Proxy Multicast Service, or Group Controller.) Each of the MKDCs 
serves its own geographic region of users. Central Authority 1 1 1 is an interconnection 
of MKDCs over secured channels, which are arranged in a hierarchical relationship 
overlapping LDAP domains, network domains, router trees and reliable transport 
trees. The secure channels linking the MKDCs are estabhshed using a public key 
exchange protocol, such that participants in the exchange can derive a common group 
key without intervention from a third party, such as another group controller. 
Altematively, protocols such as broadcast Diffie-Hellman can be used to establish the 
secure channels. MKDCs are suited to take advantage of such protocols because they 
are static with respect to joins and leaves from the multicast group. Thus, the 
frequency of a MKDC joining and leaving a group of MKDCs is relatively low. 
Further, MKDCs are inherently trusted systems. In Distributed Directory Service 
Rephcations, they build secure channels among themselves. 

In one embodiment, the Central Authority 11 1 is a distributed, near-statically 
replicatedor low latency directory, which provides the services of the KDC. In 
general, a directory creates active associations among users, applications, a network, 
and network devices. A directory is a logically centralized, highly distributed data 
repository that can be accessed by the applications. The distributed nature of 
directories is achieved by replicating data across multiple directory servers, which are 
strategically located throughout the network, in part, based upon traffic engineering 
considerations. Directories can represent network elements, services, and policies to 
enable ease of network administration and security. In particular, a directory can 
supply authentication services, whereby all users, apphcations, and network devices 
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can authenticate themselves through a common scheme, 

A directory server can be implemented as a distributed, replicated, object 
database, in which one or more master copies of the database is maintained along 
with a number of repUcas. One type of directory is Microsoft Active Directory from 
Microsoft Corporation. Active Directory is a directory that uses a data storage 
schema as defined by the Directory-Enabled Networks (DEN) definition, and is based 
upon Lightweight Directory Access Protocol (LDAP). LDAP is a directory standard 
that is based upon the ITU (Intemational Telecommunications Union) X.500 
standard. LDAP provides client access to X.500 directory servers over a TCP/IP 
(Transmission Control Protocol/Internet Protocol) based network. The details of 
LDAP are set forth in RFC 1777 and RFC 2251, which are hereby incorporated by 
reference in their entirety as if fiiUy set forth herein. X.500 employs a distributed 
approach storing information locally in Directory System Agents (DSAs). 

In the system of FIG. 1, the directory may contain user account or security 
principal information for authenticating users or services along with the shared secret 
key between the members A, B, C, D and the directory. This information may be 
stored in a database 113, which can reside within each KDC or can be shared among 
two or more KDCs. Users A, B, C, D authenticates themselves using the security 
services of the directory. Further, some of the directories can serve as CAs, or work 
cooperatively with CAs. The secured channels within the Central Authority 1 1 1 can 
be established using the key exchange method discussed below with respect to FIG. 
4A, FIG. 4B, FIG. 4C, FIG. 4D. 

FIG. 2A shows an exemplary embodiment of a clustered central KDC, CA or 
GC. The clustered central KDC 201 is shown in the form of a "server farm," 
comprising multiple KDC servers 201a-201d. KDC servers 201a-201d communicates 
through a hub 203, which may use any suitable LAN technology such as Ethemet or 
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token ring. A load balancer 205 is linked to hub 203 to load balance the traffic from 
network 207, which in this example is an IP network. The load balancer 205 provides 
virtual server capabiUty to represent KDC 201 as single entity to the users A-H. 
Thus, KDC 201 effectively has a single address, such as one IP address. The load 
balancer 205 can effectively direct traffic across all the KDC servers 201a-201d by 
mapping the one virtual IP address to the true addresses of the individual servers. 
With this approach, additional KDC servers can be readily added to supply security 
services to new users, thereby improving scalability. Normally the load balancer 205 
is implemented as an IP layer router or switch. 

FIG. 2B shows another way to scale a system in which MKDCs 251, 253, 255 
are distributed over a network at the LAN and/or WAN level. The MKDCs can be 
within the same or different domains. A domain is defined as a network or 
subnetwork that is under control by a single network management entity. 

To effectively serve users, MKDCs 251, 253, 255 conununicate over secure 
channels themselves to exchange dynamic group session keys. In this exemplary 
enterprise network, MKDC 251 and MKDC 253 are connected via an Ethemet LAN 
257, which is further linked to a network 207, such as the global packet switched 
network known as the Internet, through router 259. Another MKDC 255 resides on a 
remote LAN 263. FIG. 2B shows LAN 263 as a token ring network, however, other 
types of LANs may be utilized. Secure channels can be established among MKDCs 
251, 253, 255 using various key exchange protocols for multiparty communication, as 
discussed below in connection with FIG. 4A, FIG. 4B, FIG. 4C, FIG. 4D. 

FIG. 2C shows a distributed MKDC architecture that employs directory 
services to create secure channels among the MKDCs. As noted above, the MKDC 
functionality may include or may be a part of a Proxy Service 269. The Proxy Service 
269 enables directory principals, such as users, applications, and network devices, to 
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store Multicast Group Addresses, Topic Names, Channel Names, Event Types, or 
other abstractions used for group communication, depending on the application, in the 
directory. Proxy Service 269 has three principal functions, as shown in FIG. 2C: (1) 
providing Multicast Service in case Multicast Service is not available to a local node, 
5 (2) providing a Reliable Muhicast Stack; and (3) providing discovery of Multicast 
Addresses, Topic Names, Channels, or Event Types that can be published or 
subscribed. 

Proxy Service 269 includes a muhicast service agent (MSA) 269b and may be 
distributed across LANs and WANs, including spanning directory domains, multicast 
10 routing and transport trees in an enterprise network. Distribution may be at all levels, 
Q such as within a domain, among domains, within or among trees, etc. 

The term "Proxy Multicast Service Node" is also used in this docimient to 
refer broadly to MSAs, MKDCs, and GCs. These elements may be integrated within a 
KDC or CA or MSA, or can be implemented as separate logical elements that 
15 communicate with an MSA. Separately or collectively, these elements form an 
multicast proxy service node, 
nj As an example, FIG. 2C illustrates interaction between one MSA with various 

41 entities within one domain 261 . Domain 261 has at least one directory system agent 

(DSA) 263 and an associated KDC 271 . Also within domain 261 are a publisher 265 
20 and two subscribers 267. DSA 263, in one implementation, is a database in which 
information is stored in accordance with the X.500 information model or the LDAP 
information model. Information is exchanged with other DSAs using the Directory 
System Protocol (DSP). Such information may be stored as entries to an object class, 
in which the actual information in an entry are called "attributes." The object class 
25 defines the types of attributes an entry may possess. Subscribers 267 can access the 
directory through a Directory User Agent (DUA). 
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Publisher 265 and subscribers 267 communicate with Proxy Service 269, 
including MKDC 269a and MSA 269b, to authenticate themselves, to discover what 
events they can publish or subscribe, respectively, and to obtain a group session key. 
FIG. 2C illustrates Proxy Service 269 outside domain 261, however, it may also be 
located within the domain. To authenticate publisher 265 and subscribers 267, MKDC 
269a, a group controller, and MSA 269b utilize DSA 263, a CA and KDC 271 . The 
publisher 265, subscribers 267, MKDC 269a, and MSA 269b are security principals 
with respect to DSA 263. That is, publisher 265, subscribers 267, MKDC 269a, and 
MSA 269b can sign into the system by supplying their credentials. The MKDC 269a 
creates a group session key that is specific to a pubUsher. As a result, when the 
information is replicated across the network or enterprise, local copies of the directory 
can be used to obtain a common group session key. It cannot support dynamic 
groups, however, the MKDCs are trusted nodes that do not often fail and restart; 
accordingly, the DSA can be used to send a group session key. 

To ensure continued secured communication, changing the group session keys 
periodically among the MKDCs is desirable. MSA 269b, which is specific to 
publisher 265, generates a number of keys sufficient to enable it to cycle through 
niunerous group session keys to prevent an unauthorized user firom intercepting and 
using these keys. Such keys may be selected among MKDCs based on providing their 
date and timestamp to an algorithm that generates a key version value. 

As an example, FIG. 2C shows one domain 261 that is served by Proxy 
Service 269. However, in a complex enterprise network, MKDCs may span 
thousands of domains, posing difficulty in directory replication. One approach is to 
have subscribers, which may reside in any number of domains different fi^om a 
publisher, request group membership fi-om the KDC in the publisher's domain. 
Further, in practice a directory may have or cover any number of domains. In a 
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directory with multiple domains, each domain has a KDC and a DSA. 

FIG. 3 illustrates a secured communication system 301 that provides a secure 
channel between two participants. User A employing workstation 103 communicates 
with another workstation 105 of user B over a link 107. Link 107 is established over 
network 101, which includes, but is not limited to, a LAN, a WAN, the global packet- 
switched network known as the Internet, a wireless transmission medium, or any 
other medium for exchanging information between the participants. In addition, link 
107 may be non-secure, thereby allowing third party access to information transmitted 
by the link 107, or alternatively, Unk 107 may be secure. 

Workstations 103, 105 have components with complementary functions. 
Workstation 103 of user A includes a key generator 103b and a cryptographic device 
103a. Key generator 103b generates public and private keys used for encrypting and 
decrypting information exchanged with workstation 105 of user B. Cryptographic 
device 103a encrypts and decrypts information exchanged with workstation 105 using 
private and pubUc keys generated by key generator 103b. Similarly, workstation 105 
includes a key generator 105b and a cryptographic device 105a. Key generator 105b 
supphes public and private keys that are used to establish a secured link 107 with 
workstation 103. Information exchanged with workstation 103 is encrypted and 
decrypted by cryptographic device 105 a using private and public keys generated by 
key generator 105b. 

Participants 103, 105 can utilize various key exchange protocols, such as the 
Diffie-Helhnan method or the method discussed below, to exchange their keys. As a 
resuh, participants 103, 105 can securely exchange information over link 107 using a 
public key exchange protocol such that an eavesdropper having access to ciphertext 
transmitted on link 107 cannot feasibly decrypt the encrypted information. 
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A known public key exchange method is the Diffie-Helhnan method described 
in U.S. Pat. No. 4,200,770. The Diffie-Helhnan method relies on the difficulty 
associated with calculating discrete logarithms in a finite field. According to this 
method, two participants, A and B, each select random large numbers a and b, which 
are kept secret. A and B also agree pubUcly upon a base number p and a large prime 
number q, such that p is primitive mod q. A and B exchange the values of p and q 
over a non-secure channel or publish them in a database that both can access. Then A 
and B each privately computes public keys A and B, respectively, as follows: 
A privately computes a pubhc key A as : A = p** mod (q) (1) 
B privately computes a pubHc key B as: B = p^ mod (q) (2) 
A and B then exchange or publish their respective public keys A and B and determine 
private keys k^ and k,, as follows: 

A computes a private key k^ as: k^ = B * mod (q) (3) 
B computes a private key k^ as: k^ = A mod (q) (4) 
As evident from equation (3), A's private key is a function of its own private random 
number, a, and the public key, B. As it tums out, A and B arrive at the shared secret 
key based upon: 

k3 = B' mod (q) and k^ = A^ mod (q) 

Substituting for A and B using equations (1) and (2) above yields: 

k, = (p^ mod (q)y mod (q) and k^, = (p' mod iq)f mod (q) 
k3 = p^mod(q) and kt = p'^mod(q) 

Therefore, kj = ki,. 

Using the Diffie-Helbnan protocol, A and B each possesses the same secure 
key ka, k^, which can then be used to encrypt messages to each other. An 
eavesdropper who intercepts an encrypted message can recover it only by knowing 
the private values, a or b, or by solving an extremely difficult discrete logarithm to 
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yield a or b. Thus, the Diffie-Hellman protocol provides a relatively secure approach. 

Other approaches for key exchange that are suitable for use in embodiments of 
the present invention are disclosed in co-pending application Ser. No. 09/393,410, 
filed September 10, 1999, and naming as inventor Sunil K. Srivastava, and entitled 
"Operational Optimization of a Shared Secret Ddffie-Hellman Key 
Exchange Among Broadcast or Multicast Groups," the entire disclosure of 
which is hereby incorporated by reference as if fully set forth herein, and in co- 
pending application Ser, No. 09/393,41 1, filed on September 10, 1999, and naming as 
inventor Sunil K. Srivastava, and entitled "PROCESSING METHOD FOR KEY 
EXCHANGE Among Broadcast or Multicast Groups That Frovtoes A More 
Efficient Substitute for Diffie-Hellman Key Exchange," the entire 
disclosure of which is hereby incorporated by reference as if fully set forth herein. 

FIG. 4A shows a broadcast version of the Diffie-Helhnan method involving 
three users A, B, C, Initially, each of the participants A, B, C randomly generates 
private integers, a, b, and c, respectively. Thereafter, they compute their public keys, 
as in step 402. These public keys are computed as follows: 

A = p^mod(q) (5) 
B=p^mod(q) (6) 
C = p^mod(q) (7). 
Next, in step 404, user A sends message C = C mod (q) to user B. In turn, B 
transmits the message, A' = A^ mod (q) to C, as shown by step 406. 

In step 408, user C sends A the message B' = B' mod (q). As shown in step 
410, the users are then able to arrive at a shared secret key, k, by computing: 
A computes k: k = B'' mod (q) = p'*^ mod (q) (8) 
B computes k: k = C'^ mod (q) = p'^ mod (q) (9) 
C computes k: k = A'' mod (q) = p'*^ mod (q) (10) 
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The method establishes a secure communication channel among users A, B, and C. 
Although three users are discussed in the above example, the Diffie-Hellman key- 
exchange method applies to any number of users. 

FIG. 4B shows another public key exchange protocol that is based 
mathematically on the Diffie-Hellman method and that addresses multicast group 
membership two entities at a time. An entity may comprise one or more nodes. In 
this example, a multicast group comprises users A, B, C, D of the network of FIG. 1. 
Initially, assume that users A, B use workstations 103, 105 to establish a common 
shared key to securely commxmicate between themselves. Conceptually, users A, B 
form a single entity 441 and a subsequent user or node seeking to join the multicast 
group effectively views the previously formed multicast group as a single unit. 
Hence, users A, B are treated as one entity with respect to arriving at a new shared 
secret key with a new group member. Only one user, A or B, needs to conmiunicate 
with the new multicast group member, user C. In the preferred embodiment, the user 
who last joins the multicast group is designated as the node that relays the group's 
information to the new user. 

Using the approach of the second patent application referenced above, entitled 
"PROCESSING METHOD FOR KEY EXCHANGE AMONG BROADCAST OR MULTICAST 

Groups That Provides A More efficient Substitute for Diffie-Hellman 
Key Exchange," a current multicast group or entity 441 has two users A, B. B is 
the designated node, because B can be considered as having joined with A. 
Alternatively, the designated node can be determined according to physical proximity 
to the new node, or other metrics such as telecommunication cost, reliabihty, link 
utilization, etc. Once entity 441 and user C arrive at a new shared secret key, they 
form a new entity 443, constituting a new multicast group that subsumes multicast 
group 441. 
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If user D wishes to join the multicast group, only one of the users among A, B, 
C needs to share the group's public value with user D. Because user C was the last 
member to join, it forwards the group's public value to user D, who may then 
compute the shared secret key. The foregoing binary approach of determining a 
shared secret key between two entities at a time, as further described with respect to 
FIG. 4C and FIG. 4D, results in a greatly reduced number of messages exchanged 
among the group members over the standard broadcast Diffie-Helhnan approach. 

FIG. 4C is a flow diagram showing a method of carrying out the binary 
approach. The method assumes that a multicast group of one or more nodes or users 
is in existence. If two or more nodes make up the multicast group, the method further 
assxmies that the group is communicating over a secure channel such that each 
member of the multicast group possesses or has knowledge of the group shared secret 
key. 

In step 401, a new node that wishes to join the existing multicast group 
communicates the new node's pubhc value to the muhicast group. In an exemplary 
embodiment, step 401 is carried out by a directory that stores the pubhc value for 
ready access by the members of the multicast group. 

In step 403, the multicast group sends the new node the collective pubhc value 
of the multicast group. The computation of this public value is more fully discussed 
below with respect to FIG. 4D. Based upon each other's pubhc key, the new node 
and the multicast group members independently compute a new group shared secret 
key, as shown by step 405. With this new group shared secret key, all members of the 
new multicast group can exchange their private values, as shown by step 407. 
Accordingly, secure communication can be achieved. 

FIG. 4D is a flow diagram of the foregoing process in greater detail FIG. 4D 
shows a key exchange protocol to arrive at a shared secret key in a context involving 
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four nodes or users A, B, C, D. In step 41 1, A and B compute a shared secret key, k = 
p*^ mod (q), thereby forming entity 441 in a manner similar to the standard two party 
Diffie-Helhnan method. A and B each publishes its respective public key (A = p* mod 
(q) and B = p^ mod (q)). User A obtains B's public key to compute B * mod (q), 
which equals p*^ mod (q); user B performs a similar computation based on A's pubUc 
key. 

Once A and B have reached a shared secret key, they exchange their private 
numbers, a and b. Numbers a and b are randomly generated integers and are 
embedded in messages that are sent by users A and B to each other. These messages 
can be signed by the sending node using a private key that differs from the sending 
node's private number. In one embodiment, the private key may be a permanent 
private key. By using separate private keys, the multicast group obtains an additional 
level of security. 

Assume that currently, the multicast group includes users A and B; however, 
user C has a message to send to both A and B. As a result C seeks to join the 
multicast group. In step 413, user C communicates its public value, C = p*" mod (q), 
to the other users, A and B, within the established multicast group. Next, as shown in 
step 415, a pubhc key value, AB, determined by users A and B, is sent to user C by 
either A or B. 

AB = k,b^^ mod (q) = pf^'>^^'^ mod (q) (1 1) 

According to Equation (11), the private number of the formed entity or multicast 
group, AB, is the product of the individual private numbers a and b, raised to a power 
that is a function of the number of nodes within the formed entity. Thus, the private 
value of AB is (ab)l 

In the preferred embodiment, the last member to join the group has 
responsibihty of transferring the collective public key value to a "joining" node. 
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Thus, user B transmits public key AB to C. At the time of joining the multicast 
group, new member C has knowledge of only one entity, which may be one or more 
nodes; in this example, A and B form one entity. A and B independently compute the 
shared secret in step 417, using Equation 12: 

= C^^'^^'> mod (q) = p^^'^^'^ mod (q) = p^'^*''^ mod (q) (12) 
A and B are able to compute the shared secret key because they know each other's 
randomly generated private numbers a and b. This computation, operationally, can be 
accomplished by tracking the number of times each of the nodes has undergone 
multicast membership joins. In this instance, A and B have been involved with 
multicast joins twice, while user C has done so only once. 

User C computes the group shared secret key as follows: 
k,^ = (ABf mod (q) = p^^'><^'>^ mod (q) = p^^'"'>^ mod (q) (13) 
Now that a group shared secret key has been computed by all the members of the 
"new" multicast group, the members exchange their private values to begin 
conraiunicating over a secure channel, as shown in step 419. 

Assiune that another user D now wants to commimicate with all the users of 
the multicast group. User D conmiunicates its pubHc value, D (= p** mod (q)) to the 
multicast group, as shown by step 421. In step 423, the multicast group transfers an 
agreed upon collective public value, ABC, to D. According to one embodiment, C is 
designated as the member to convey value, ABC, to user D, and the value ABC is: 
ABC = K^'"^ mod (q) - p<«^*'K«^>^x^*-» mod (q) = p^^^^^'^^^^'^'^mod q (14) 
Based on Eqxiation (14), the private value for the multicast group is (ab)^(c^). Thus, 
the multicast group private value is the product of the private values of the nodes 
raised to the number of times each node has been in group formations. This is 
advantageous because the collective pubhc key can be derived by having each node 
track the number of times it has participated in multicast group formation. With this 

25 

50325-083 (WGM 1422) 

SJS 23413-2.050325.0083 



information, in step 425 the user D, as the new node, can compute a new group shared 
secret key, k^bcd: 

k,^, = (ABC)^ mod (q) = p«(^^x^^>^»<^^>^ mod (q) = pt^^'^'^Xc-z).! (^5) 
Likewise, the other members A, B, C of the multicast group calculate the new group 
shared secret key. 

In the preferred embodiment, the processes shown in FIG. 4A, FIG. 4B, FIG. 
4C, FIG. 4D may be implemented as one or more computer-executed instructions, 
processes, programs, subroutines, fimctions, or their equivalents. In an embodiment, 
each workstation 103, 105, 107, 109 is a general-purpose computer of the type shown 
in FIG. 8 and described herein in connection with FIG. 4A, FIG. 4B, FIG. 4C, FIG. 
4D. The cryptographic devices 103a, 105a and the key generators 103b, 105b are one 
or more computer-executed instructions, processes, programs, subroutines, functions, 
or their equivalents. Further, embodiments may be implemented as discrete hardware 
circuitry, a pluraUty of computer instructions (computer software), or a combination 
of discrete hardware circuitry and computer instructions. 

Once a distributed group controller or MKDC of FIG. 2 A, FIG. 2B, FIG. 2C 
has estabhshed secure conmiunication using any one of the key exchange methods, 
the distributed group controller may efficiently disseminate and maintain the group 
session keys for the members of the multicast group of users A-H. According to the 
present invention, a tree structure is used. In the tree structure, the MKDC can be 
implemented as a group controller that is joined with other MKDCs in the tree to 
enable communication of keys among them. This arrangement enables secure 
conununications between the MKDCs. 

FIG. 5 shows a binary tree structure for key management among a multicast 
group. In the binary tree approach, users, clients or nodes of a multicast group are 
mapped to leaf nodes of a binary tree 500. Root node 501 represents the distributed 
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group controller. In one embodiment, leaf nodes are associated with users A-H. Each 
leaf node forms a point-to-point secure channel with group controller 501. Thus, 
intermediate nodes 515 are not true nodes and are not associated with software or 
hardware elements of a network, but rather serve to conceptually illustrate how each 
leaf obtains the group session key (GK). 

Group controller node 501 has the responsibility of encrypting 21og2N+l keys 
and sending the keys to nodes A-H via a multicast message. The actual messages that 
are transmitted by group controller 501 contain, for example, information about the 
key's identification, revision, and version. Alternatively, group controller node 501 
may send 21og2N+l messages to each group member individually. Each leaf node A- 
H stores logjN keys, in which one of the keys is the particular node's private key and 
the remaining keys are shared among some of the other nodes. 

Labels along the branches of binary tree 500 show how the group key GK is 
encoded for each member of the multicast group. The group key xmdergoes 
successive encryption by the private keys of nodes of all branches. 

For example, for the branch comprising nodes 501, 503, 507 and user A, 
group key GK is first encrypted using the private key, Kj, of node 503. These keys 
are then encrypted using the private key, K^, of node 507. The private key of user A 
encrypts these keys. Thus, group controller 501 sends, to user A, the last encrypted 
message, Ka[Kii(K,(GK))]. When user A receives this encrypted message, it decrypts 
xising its private key and utilizes the corresponding shared keys until the group key is 
determined. Under this arrangement, no one leaf has knowledge of all the shared 
keys, thereby providing an extra level of security. 

In another embodiment, intermediate nodes 515 of the binary tree 500 
represent actual multicast group members. This arrangement more naturally 
acconmiodates superimposition of multicast routing trees, reUable multicasting 
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transport trees, hierarchical cache chaining structures, and directory trees. Using 
intermediate nodes 515, the number of group members and keys is 2^^* - 1, and each 
group member stores logj^ keys, where n defines the level in a tree, ranging from 0 to 
N, and N is the number of nodes in the tree. In contrast, an embodiment that employs 
only leaves of the binary tree 500 accommodates N nodes and 2^^^ - 1 total keys, in 
which each node has logjN keys. 

Under this scheme, there is flexibility in implementation with regard to 
joining and leaving the multicast group. The number of keys affected is essentially 
21og2N - 21og2n. In the first option, the intermediate node, for example node 503, 
behaves as a group controller for its branch by changing the keys of the affected 
nodes within its branch. This first option reduces the workload on the group 
controller 501. As a second option, the intermediate node 503 requests a new session 
key from the group controller 501 or requests permission to create a new session key. 

In the case where the group controller 501 creates a new group session key, 
the group controller 501 encrypts the new session key with the private key of the 
intermediate node 503. However, if the group session key results from a member 
leaving the multicast group, the intermediate node 503 changes its key(s) since such 
keys were known by the leaving node. To do so, the intermediate node has a separate 
secured private channel with the group controller 501 . Using this private channel, the 
intermediate node sends the group controller 501 its updated keys. Altematively, the 
intermediate node (which is acting as a sub-group controller) decrypts the group 
session key from the group controller 501 and then encrypts the group session key 
with the newly created keys associated with the affected nodes. 

In yet another embodiment of the binary tree method, the private keys of the 
nodes can be made to correspond to an address identification. Assuming that there is 
an address space of 2^ member nodes, each member is identified by a word of N bits 
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in length. For example, users A-H are assigned 000 - 1 11, respectively. Further, 
each bit in the address ID can be considered to correspond to a private key, and the 
total number of keys is 2N. 

In an exemplary embodiment, address IDs can be hierarchically assigned, in 
which the most significant bits (MSBs) represent node members closer to the root 
node and group controller. When a node joins the multicast group, group controller 
501 distributes N keys, corresponding to bit values of the joining node, by embedding 
these keys in the address identifier of the new node after version incrementing it. In 
the case where the node leaves the group, the group controller 501 communicates a 
new group session key encrypted in the remaining N keys that were unaffected by the 
node leaving. The group controller 501 also broadcasts the new version of the 
affected N keys encrypted in the new group key and the old set of N keys. 

IP address and time coordinates of a directory node may be used to derive a 
unique address identifier for a node that is joining a multicast group. However, this 
does not result in a contiguous sequence or address space of the identifiers. To obtain 
identifiers that are within a contiguous address space, the identifiers may be issued by 
a central registration authority or appropriately hashed. Directory replication can be 
utilized to implement a distributed MKDC, as shown in FIG. 2B and FIG. 2C. 
According to a preferred embodiment, an X. 5 00 directory or LDAP directory operates 
as a mechanism for key distribution and provides a logical infi-astructure for the tree 
approach described above. Such directory mechanisms inherently include a 
replication capability. When directory replication is carried out, a copy of the 
directory database is automatically distributed to and stored in a different logical 
domain. Nodes within the different logical domain can access a local replica of the 
directory for needed information, rather than sending a request for service across the 
network. 
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In this configuration, a MKDC and MSA for a domain from which a pubHsher 
is publishing events may use directory repUcation to store and distribute ID-based 
keys. The directory provides a repository of all versions of private keys for each 
MDCS and each MSA node. Using these keys, private secured channels are built 
using a primary group controller or group manager using the mechanisms described 
herein. The group controller stores the same set of keys and version information. 
Communication between group controllers includes version information in headers. 
Keys may be synchronized using the version information. A new group session key 
may be generated by a particular MKDC and MSA acting as a master group 
controller. Thus, when a new group session key is generated, it can be stored only in 
the local domain. Directory replication then occurs, and thereafter, an MKDC can 
obtain a conmion group session key from a local copy of the directory. Normally, the 
MSA and MKDC will not start up or shut down (come up and down) very often. 
Therefore, the frequency of updates is low, and at the time of an update, a large 
number or block of keys for various versions can be distributed using directory 
replication, 

FIG. 6 A is a flow chart that shows a process of a node joining a multicast 
group according to the binary tree algorithm of FIG. 5. In relation to FIG. 5, joining 
the multicast group means assuming a leaf position on the binary tree 500 or creating 
and storing a new node at the level of leaf nodes A-H. Because the shared keys along 
a branch with the new leaf are required to be updated, those nodes along this 
particular branch are affected by the addition. 

As shown by step 601, a node that desires to be a part of the multicast group 
first sends a request to the group controller 501 . The group controller 501 determines 
which nodes are affected by this join, as shown by step 603. The group controller 501 
generates new versions of the keys of the affected nodes, as shown by step 605. 
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In step 607, group controller 501 sends these new versions of the shared keys 
and a unique private key to the new node. In step 609 the group controller 501 
transmits a message to the affected nodes, instructing the nodes to update their keys 
by changing the revision numbers. Each of the affected nodes, in response to the 
message, derives a new version of its keys, as shown by step 611. In the preferred 
embodiment, each affected node performs a one way hash to compute the new version 
of the keys. Such an approach permits the generation of unique keys to be 
synchronized between the member nodes and the group controller without having to 
transmit the actual keys, thereby reducing the probability of security leaks. 

FIG. 6B provides an exemplary illustration of a user joining the multicast 
group. In this example, user A, who seeks to join, sends a request message to group 
controller node 501 over an unsecured channel Because user A belongs in the left 
branch 621 of the binary tree 500, the affected nodes in this instance are nodes 503, 
507. These nodes are required to update their keys by performing a one way hash 
function on the current version of their keys when instructed by group controller 501. 
The group controller 501 transmits the shared keys of the nodes along branch 621 to 
user A along with user A's private key. Thus, user A is able to derive the group 
session key and securely communicate with the other members of the multicast group. 
The group controller 501 is also responsible for managing the keys when a node 
leaves the multicast group. 

FIG. 7 A is a flow chart that shows a process of managing keys within the 
multicast group when a group member leaves. In this case, all the keys known to the 
"leaving" node are version controlled to prevent such user from intercepting future 
messages exchanged among the multicast group. 

Accordingly, in step 701, group controller 501 generates a new key for the 
parent of the leaving node as well as all ancestral nodes until the root node is reached. 
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The group controller 501 also creates new keys for the sub-branches hanging off from 
the sub-nodes that fall on the path from the departed node to the root node. In 
particular, the group controller 501 encrypts a new key of the parent node with the 
adjacent node's private key, as shown by step 703. 

The key of the immediate ancestral node (which in this instance is the 
grandparent of the leaving node) is encrypted with the keys of both affected and 
unaffected descendent nodes, as indicated by step 705. The group controller 501 then 
determines whether the new root key has been encrypted, as shown by step 707. If 
the root key 501 has not been encrypted, then step 705 is repeated until the root key 
501 is encrypted with its two child nodes. In fact, once the root node 501 has been 
updated, all the keys are transferred to each of the users of the affected branch 720 in 
one message containing 21og2N+l keys. 

FIG. 7B is a diagram that illustrates the process of FIG. 7A in an example case 
in which user C terminates its membership in the multicast group. As described 
above, group controller 501 creates a new key for each ancestral node along the path 
720 of the leaving node; i.e., node 509 of user C, a new key for the grandparent node 
503, and a new group session key. 

Accordingly, a directory may be used as infrastructure to build secure 
communications among a plurality of MKDCs. Each address has two keys for each 
bit in the address value. If the value of a particular bit is 1, then the first key is used, 
otherwise the second key is used. All nodes have overlapping keys and no single node 
has all keys. An administrator can determine a group session key, update one 
directory domain with the group session key, and directory repUcation then causes the 
keys to be replicated. As a result, keys become locally available to all nodes that need 
them. 
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FIG. 8 illustrates a computer system 801 upon which an embodiment may be 
implemented. Such a computer system 801 may be configured as a user node or 
server node to provide the various security and directory services as earher discussed. 
Computer system 801 includes a bus 803 or other commxmication mechanism for 
communicating information, and a processor 805 coupled v^ith bus 803 for processing 
the information. Computer system 801 also includes a main memory 807, such as a 
random access memory (RAM) or other dynamic storage device, coupled to bus 803 
for storing information and instructions to be executed by processor 805. In addition, 
main memory 807 may be used for storing temporary variables or other intermediate 
information during execution of instructions to be executed by processor 805. 
Notably, the values associated with tracking the number of times a node engages in 
multicast group formation may be stored in main memory 807. Computer system 801 
further includes a read only memory (ROM) 809 or other static storage device 
coupled to bus 803 for storing static information and instructions for processor 805. 
A storage device 811, such as a magnetic disk or optical disk, is provided and coupled 
to bus 803 for storing information and instructions. With respect to the system of 
FIGs. 2A-2C, information on the binary tree structure can be stored in device 81 1 for 
manipulation by processor 805. 

Computer system 801 may be coupled via bus 803 to a display 813, such as a 
cathode ray tube (CRT), for displaying information to a computer user. An input 
device 815, including alphanumeric and other keys, is coupled to bus 803 for 
commxmicating information and command selections to processor 805. Another type 
of user input device is cursor control 817, such as a mouse, a trackball, or cursor 
direction keys for communicating direction information and command selections to 
processor 805 and for controUing cursor movement on display 813, 
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Embodiments are related to the use of computer system 801 to implement a 
public key exchange encryption approach for securely exchanging data between 
participants. According to one embodiment, the public key exchange encryption 
approach is provided by computer system 801 in response to processor 805 executing 
one or more sequences of one or more instructions contained in main memory 807. 
Such instructions may be read into main memory 807 from another computer- 
readable medium, such as storage device 811. Execution of the sequences of 
instructions contained in main memory 807 causes processor 805 to perform the 
process steps described herein. One or more processors in a multi-processing 
arrangement may also be employed to execute the sequences of instructions contained 
in main memory 807. In alternative embodiments, hard-wired circuitry may be used 
in place of or in combination with software instructions. Thus, embodiments are not 
hmited to any specific combination of hardware circuitry and software. 

The term "computer-readable medium" as used herein refers to any medixxm that 
participates in providing instructions to processor 805 for execution. Such a medium 
may take many forms, including but not limited to, non-volatile media, volatile media, 
and transmission media. Non- volatile media includes, for example, optical or magnetic 
disks, such as storage device 811. Volatile media includes dynamic memory, such as 
main memory 807. Transmission media includes coaxial cables, copper wire and fiber 
optics, including the wires that comprise bus 803. Transmission media can also take 
the form of acoustic or light waves, such as those generated during radio wave and 
infrared data communications. 

Common forms of computer-readable media include, for example, a floppy 
disk, a flexible disk, hard disk, magnetic tape, or any other magnetic medium, a CD- 
ROM, any other optical medium, punch cards, paper tape, any other physical medium 
with patterns of holes, a RAM, a PROM, and EPROM, a FLASH-EPROM, any other 
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memory chip or cartridge, a carrier wave as described hereinafter, or any other 
medium from which a computer can read. 

Various forms of computer readable media may be involved in carrying one or 
more sequences of one or more instructions to processor 805 for execution. For 
example, the instructions may initially be carried on a magnetic disk of a remote 
computer. The remote computer can load the instructions relating to computation of 
the shared secret key into its dynamic memory and send the instructions over a 
telephone line using a modem. A modem local to computer system 801 can receive 
the data on the telephone line and use an infrared transmitter to convert the data to an 
infrared signal. An infrared detector coupled to bus 803 can receive the data carried 
in the infrared signal and place the data on bus 803. Bus 803 carries the data to main 
memory 807, from which processor 805 retrieves and executes the instructions. The 
instructions received by main memory 807 may optionally be stored on storage 
device 811 either before or after execution by processor 805. 

Computer system 801 also includes a commimication interface 819 coupled to 
bus 803. Communication interface 819 provides a two-way data communication 
coupling to a network link 821 that is connected to a local network 823. For example, 
commimication interface 819 may be a network interface card to attach to any packet 
switched LAN. As another example, communication interface 819 may be an 
asymmetrical digital subscriber line (ADSL) card, an integrated services digital 
network (ISDN) card or a modem to provide a data communication connection to a 
corresponding type of telephone line. Wireless links may also be implemented. In 
any such implementation, communication interface 819 sends and receives electrical, 
electromagnetic or optical signals that carry digital data streams representing various 
types of information. 
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Network link 821 typically provides data communication through one or more 
networks to other data devices. For example, network link 821 may provide a 
connection through local network 823 to a host computer 825 or to data equipment 
operated by an Intemet Service Provider (ISP) 827. ISP 827 in turn provides data 
conraiunication services through the Intemet 829. Local network 823 and Intemet 
829 both use electrical, electromagnetic or optical signals that carry digital data 
streams. The signals through the various networks and the signals on network link 
821 and through communication interface 819, which carry the digital data to and 
from computer system 801, are exemplary forms of carrier waves transporting the 
information. 

Computer system 801 can send messages and receive data, including program 
code, through the network(s), network link 821 and communication interface 819. In 
the Intemet example, a server 831 might transmit a requested code for an application 
program through Intemet 829, ISP 827, local network 823 and communication 
interface 819. One such downloaded appUcation provides a public key exchange 
encryption approach for securely exchanging data between participants as described 
herein. 

The received code may be executed by processor 805 as it is received, and/or 
stored in storage device 81 1 , or other non- volatile storage for later execution. In this 
manner, computer system 801 may obtain application code in the form of a carrier 
wave. 
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The techniques described herein provide several advantages over prior pubhc 
key exchange encryption approaches for securely exchanging data among multiple 
participants using directory replication. By utihzing private keys that can serve as 
unique IDs, the keys can be stored efficiently. Further, the distributed group 
controllers exhibit improved system throughput and scalability. 

As described in more detail herein, each DSA has a DRP component that can 
repUcate objects and attributes for Security Principal Ids, Group Session Keys and 
Private Keys, Multicast Group Multicast Address, Topic Names, Event Types and 
Channels. They build a point to point secured channel using KDC or CA. Then using 
replicated keys and security principal Ids the system can create a secured channel of 
MKDC, MSAs, and GCs. 

In the foregoing specification, particular embodiments have been described. It 
will, however, be evident that various modifications and changes may be made 
thereto without departing fi-om the broader spirit and scope of the invention. The 
specification and drawings are, accordingly, to be regarded in an illustrative rather 
than a restrictive sense. 
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CLAIMS 

What is claimed is: 



1 1 . A method for communicating a session key from a first multicast proxy 

2 service node of a secure multicast group to a plurality of other multicast proxy 

3 service nodes of the multicast group in a communication network, wherein 

4 each of the multicast proxy service nodes is capable of estabhshing multicast 

5 communication and serving as a key distribution center, the method 

6 comprising the steps of: 

7 creating and storing a group session key associated with the multicast group in 

8 a directory; 

9 authenticating the first muUicast proxy service node with a subset of the 

10 multicast proxy service nodes that are affected by an addition of the 

1 1 first multicast proxy service node to the multicast group, based on the 

12 group session key stored in the directory; 

1 3 receiving a plurality of private keys from the subset of nodes; 

14 receiving a new group session key for the multicast group, for use after 

1 5 addition of the first multicast proxy service node, from a local 

1 6 multicast proxy service node that has received the group session key 

1 7 through periodic replication of the directory; 

1 8 communicating the new group session key private key to the first multicast 

1 9 proxy service node; 

20 commimicating a message to the subset of nodes that causes the subset of 

21 nodes to update their private keys. 
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2. A method as recited in Claim 1 , wherein authenticating the plurality of 
multicast proxy service nodes includes authenticating the plurality of multicast 
proxy service nodes based on a directory that comprises a directory system 
agent (DSA) that communicates with one or more of the multicast proxy 
service nodes and a replication service agent (RS A) that replicates attribute 
information of the one or more multicast proxy service nodes. 

3. A method as recited in Claim 1 , wherein receiving a new group session key 
includes receiving the new group session key from a node of a directory that 
comprises a directory system agent (DSA) for communicating with one or 
more of the muUicast proxy service nodes and a replication service agent 
(RS A) for replicating key information of the one or more multicast proxy 
service nodes. 

4. A method as recited in Claim 3, further comprising the step of signaling the 
replication service agent to carry out replication by storing an updated group 
session key in a local node of the directory. 

5. A method as recited in Claim 1, further comprising distributing a group 
session key to all nodes by creating and storing the group session key using a 
first multicast proxy service node of one domain of the directory; replicating 
the directory; and obtaining the group session key from a local multicast 
proxy service node that is a repUca of the first multicast proxy service node. 
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16. A method as recited in Claim 1 , further comprising distributing a group 

2 session key to all nodes by creating and storing the group session key using a 

3 first multicast proxy service node of one domain of the directory; replicating 

4 the directory; and obtaining the group session key fi"om a local multicast 

5 proxy service node that is a replica of the first multicast proxy service node. 

1 7, A communication system for managing addition of a first multicast proxy 

2 service node to a secure multicast group that includes a plurality of other 

3 multicast proxy service nodes in a communication network, wherein each of 

4 the muhicast proxy service nodes is capable of establishing multicast 

5 communication and serving as a key distribution center, the conunimication 

6 system comprising: 

7 a group controller that creates and manages secure multicast communication 

8 among the other multicast proxy service nodes, having a private key; 

9 a computer-readable medium comprising one or more instructions which, 

10 when executed by one or more processors, cause the one or more 

1 1 processors to carry out the steps of: 

12 creating and storing a group session key associated with the multicast group in 

13 a directory; 

14 authenticating the first multicast proxy service node with a subset of the 

15 multicast proxy service nodes that are affected by an addition of the 

1 6 muhicast proxy service node to the multicast group, based on the 

17 group session key stored in the directory; 

18 receiving a plurality of private keys fi-om the subset of nodes; 
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19 receiving a new group session key for the multicast group, for use after 

20 addition of the first multicast proxy service node, from a local 

2 1 multicast proxy service node that has received the group session key 

22 through periodic replication of the directory; 

23 communicating the new group session key private key to the first multicast 

24 proxy event service node; 

25 commxmicating a message to the subset of nodes that causes the subset of 

26 nodes to update their private keys. 

18. A method for creating a secure multicast or broadcast group among a plurahty 

2 of multicast proxy event service nodes, the method comprising the steps of: 

3 authenticating the plurality of multicast proxy service nodes via a directory 

4 that includes a directory system agent (DSA) for conununicating with 

5 one or more of the multicast proxy service nodes and for replicating 

6 attribute information of the one or more multicast proxy service nodes; 

7 generating private keys for each of the multicast proxy service nodes, the 

8 private keys providing unique identification within the tree structure; 

9 generating a first group session key for estabhshing the secure multicast or 

10 broadcast group among the multicast proxy service nodes; 

1 1 distributing the first group session key among the multicast proxy service 

12 nodes by using periodic directory replication of the attribute 

1 3 information, wherein the attribute information comprises the first 

14 group session key, and the private keys; and 

1 5 forming a second secure multicast group among the plurality of client nodes 

16 by one of the leaf nodes using a second group session key obtained 



50325-083 (WGM 1422) 

SJS 23413-2.050325.0083 



41 



from a local replica of the node that generated the first group session 
key. 



9. The method as recited in Claim 8, further comprising selectively updating the 
first group session key and the private keys using the DSA, wherein the step 
of selectively updating comprises: 

detecting whether one of the nodes is leaving the secure multicast or broadcast 
group; 

determining which of other nodes are affected by deletion of the leaving node; 
updating the private keys of the affected intermediate nodes; 
generating a new group session key; 

modifying the attribute information based upon the updated private keys and 

the new group session key; and 
distributing the modified attribute information using directory replication. 

10. The method as recited in Claim 8, further comprising selectively updating the 
first group session key and the private keys via the DSA, wherein the step of 
selectively updating comprises: 

receiving a request message from a new node to join the secure multicast or 
broadcast group; 

determining which other nodes are affected by addition of the joining node; 
updating the private keys of the affected nodes; 
generating a new group session key and a private key of the new node; 
modifying the attribute information based upon the updated private keys, the 

new group session key, and the private key of the new node; and 
distributing the modified attribute information using directory replication. 
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26 among the plurality of multicast proxy service nodes and distributes 

27 the first group session key to other nodes in the group ixsing directory 

28 rephcation. 

1 12. A computer system for establishing a secure multicast or broadcast group, the 

2 computer system comprising: 

3 a communication interface for communicating with a plurality of extemal 

4 computer systems and for interfacing a directory to authenticate the 

5 computer system and the plurality of extemal computer systems; 

6 a bus coupled to the communication interface for transferring data; 

7 one or more processors coupled to the bus for selectively generating a group 

8 session key and private keys corresponding to the pluraUty of extemal 

9 computer systems, and for logically operating with the pluraUty of 

10 extemal computer systems according to a tree structure, the tree 

1 1 structure having a root node, intermediate nodes, and leaf nodes, 

12 wherein the computer system is mapped to the root node, the plurahty 

1 3 of extemal computer systems are mapped to the intermediate nodes 

14 and the leaf nodes, the corresponding private keys providing unique 

1 5 identification of respective plurality of extemal computer systems 

16 within the tree structure, the group session key being distributed using 

17 directory replication using a directory system agent of the directory; 

18 and 

19 a memory coupled to the one or more processors via the bus, the memory 

20 includes one or more sequences of instructions which when executed 

21 by the one or more processors cause the one or more processors to 

22 perform the step of selectively updating the group session key and the 
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23 private keys in response to whether a new client joins or a one of the 

24 client nodes leaves the multicast or broadcast group. 

1 13. A computer-readable medium carrying one or more sequences of instructions 

2 for communicating a session key from a first muUicast proxy service node of a 

3 secure multicast group to a plurality of other multicast proxy service nodes of 

4 the multicast group in a communication network, wherein each of the 

5 multicast proxy service nodes is capable of estabHshing multicast 

6 conunimication and serving as a key distribution center, wherein execution of 

7 the one or more sequences of instructions by one or more processors causes 

8 the one or more processors to perform the steps of: 

9 creating and storing a group session key associated with the multicast group in 

10 a directory; 

1 1 authenticating the first multicast proxy service node with a subset of the 

12 multicast proxy service nodes that are affected by an addition of the 

13 first muhicast proxy service node to the multicast group, based on the 

14 group session key stored in the directory; 

15 receiving a plurality of private keys from the subset of nodes; 

1 6 receiving a new group session key for the multicast group for use after 

1 7 addition of the first multicast proxy service node from a local multicast 

1 8 proxy service node that has received the group session key through 

1 9 periodic rephcation of the directory; 

20 commimicating the new group session key private key to the first multicast 

2 1 proxy service node; 

22 communicating a message to the subset of nodes that causes the subset of 

23 nodes to update their private keys. 
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ABSTRACT OF THE DISCLOSURE 

An approach for establishing secure multicast communication among multiple 
multicast proxy service nodes is disclosed. The multicast proxy service nodes, which 
can be distributed throughout an enterprise domain, are organized in a logical tree that 
mimics the logical tree arrangement of domains in a directory server system. The 
attributes of the multicast proxy service nodes include the group session key and the 
private keys of the multicast proxy service nodes that are members of the multicast or 
broadcast groups. The private keys provide unique identification values for the 
multicast proxy service nodes, thereby facilitating distribution of such keys. Because 
keys as well as key version information are housed in the directory, multicast security 
can be achieved over any number of network domains across the entire enterprise. 
Key information is stored in, and the logical tree is supported by, a directory service. 
RepHcation of the directory accomplishes distribution of keys. Multicast proxy 
service nodes may obtain current key information from a local copy of the replicated 
directory. 
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